feat: upgrade lego to v5.1.0 and add Dynadot DNS provider#12829
feat: upgrade lego to v5.1.0 and add Dynadot DNS provider#12829rowanchen-com wants to merge 3 commits into
Conversation
|
Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
lego v5 introduces several breaking API changes that touch every entry
point we use. This commit migrates 1Panel's SSL stack to v5 and adds a
data migration so existing certificates keep auto-renewing without
operator action.
Code changes:
- AcmeUser.Key is now a crypto.Signer (was crypto.PrivateKey); same for
the key returned by GetPrivateKeyByType. Account registration is now
an *acme.ExtendedAccount (was *registration.Resource).
- A new parsePrivateKeyPEM helper accepts both v4 (SEC1 EC, PKCS#1 RSA)
and v5 (PKCS#8) key formats, so account/certificate keys persisted
under v4 keep loading after the upgrade.
- Obtain/ObtainForCSR/Revoke now require a context.Context.
- dns01.AddRecursiveNameservers and dns01.AddDNSTimeout were removed.
Recursive nameservers and timeout are now passed via
dns01.SetDefaultClient(dns01.NewClient(&dns01.Options{...})).
- ObtainRequest disables the CN by default in v5; we set
EnableCommonName: true to preserve the v4 behaviour for legacy
clients (Java keystores, embedded routers, etc.) that still rely on
the CommonName field.
- lego.CertificateConfig.KeyType was removed (the key type is taken
from the user's account); the matching code path is dropped.
- certificate.Resource.Domain was renamed to Domains (now []string).
- log.Logger is now an *slog.Logger; switch website_ssl.go over to slog
with a TextHandler that writes to the existing file logger.
KeyType migration:
- certcrypto.KeyType string values were renamed in v5: P256->EC256,
P384->EC384, 2048->RSA2048, 3072->RSA3072, 4096->RSA4096,
8192->RSA8192. A gormigrate migration rewrites the key_type column
in website_acme_accounts, website_ssls and website_cas on first
start, so old certificates renew under their new names automatically.
- A normalizeKeyType helper falls back to the same mapping at runtime,
in case the database migration has not yet run.
- Frontend KeyTypes select options and four form-initial keyType
defaults are updated to the v5 form so newly created accounts also
use the new strings.
Build and vet pass on linux/amd64 (GOOS=linux GOARCH=amd64 go build/vet
./...).
Dynadot was added to upstream lego in v5.1.0 (go-acme/lego#3125). Wire it into the same DNS provider switch the other 25 providers use, and surface it in the frontend so users can pick it in the DNS account dialog. DnsPod is removed from the DNS provider list. lego v5 has no DnsPod implementation; the previous frontend already showed a deprecation hint pointing at TencentCloud, which is now the recommended way to manage DNSPod-hosted zones (the underlying API is the same).
…ace) Three issues raised on the PR: 1. Backend KeyType validators in WebsiteAcmeAccountCreate, WebsiteCACreate and WebsiteCAObtain still required the v4 strings (P256/P384/2048/...), so after the frontend started sending v5 strings (EC256/RSA2048/...) the create/obtain endpoints would 422. Validators now accept both v4 and v5 forms; service-layer normalizeKeyType continues to handle either case. 2. getDNSProviderConfig had no default branch in its switch. A DNS account with type `DnsPod` (kept on disk after the v5 upgrade) silently fell through and returned (nil, nil), making the DNS-01 step fail far away from the real cause. Add an explicit DnsPod branch that returns a clear `removed in lego v5; switch to TencentCloud` error, plus a generic default for any other unknown type. Surface the same warning in the UI: the DNS account list shows a `removed` tag on DnsPod rows, and the SSL list shows the same tag on certificates that are still bound to a DnsPod account, so users see the broken state before auto-renewal silently fails. 3. lego v5 keeps the recursive-resolver Client and the LEGO_DISABLE_CNAME_SUPPORT environment switch as process-wide globals, and reads dns01.DefaultClient() inside its own propagation precheck loop. Two concurrent SSL applications with different nameserver / DisableCNAME settings could clobber each other and use the wrong resolver. Wrap the whole DNS-01 flow (UseDns through Obtain*) in a package-level mutex so one apply finishes before the next one configures the globals. i18n strings for the DnsPod removal hints are added to all 10 locales to match the existing translation coverage of nearby keys.
35bf2db to
0e4a940
Compare
What this PR does / why we need it?
Adding Dynadot requires lego v5.1.0 (the provider is not in v4), so this
PR does both at once: upgrade lego from v4.35.2 to v5.1.0, and wire up
the new Dynadot DNS provider.
Summary of your change
Commit 1 -- lego v5 upgrade
AcmeUser.Key is crypto.Signer instead of crypto.PrivateKey; account
registration is *acme.ExtendedAccount instead of *registration.Resource;
certificate.Resource.Domain was renamed to Domains ([]string).
use dns01.SetDefaultClient(dns01.NewClient(&Options{...})) instead. The
custom recursive nameserver fields in the website SSL form keep working.
is set to true to keep the v4 behaviour, otherwise older clients (Java
keystores, embedded routers) that still rely on the CN field would fail
the TLS handshake.
is dropped.
*log.Logger via slog.NewTextHandler so SSL apply logs still land in
SSLLogDir.
Backward compatibility for users upgrading from v4
P384 -> EC384, 2048 -> RSA2048, 3072 -> RSA3072, 4096 -> RSA4096,
8192 -> RSA8192. A gormigrate migration rewrites the key_type column in
website_acme_accounts, website_ssls and website_cas on first start, so
old certificates renew automatically. A normalizeKeyType helper also
handles the mapping at runtime as a safety net.
(RSA). A new parsePrivateKeyPEM helper tries PKCS#8 first and falls back
to the legacy formats, so existing account keys persisted under v4 keep
loading without manual conversion.
defaults are updated to the v5 form.
Commit 2 -- Dynadot / DnsPod
the other API-key/secret based providers.
implementation). The startup migration counts existing DnsPod rows in
website_dns_accounts and logs a warning so the operator can switch them
to TencentCloud, which now manages DNSPod-hosted zones via the same
underlying API. Existing rows are not deleted.
Tested locally against AliYun, Spaceship, CloudFlare and Dynadot.
Certificates issued under v4 renew under the v5 binary in seconds (LE
authorization is reused), and brand-new domains go through the full
DNS-01 flow correctly.
Please indicate you've done the following: